Internet Security Overview
The Internet was not originally designed to be secure. The development of the ARPANET as the first “network of networks” was driven by the need for open communication between scientists and researchers. It is often desirable, however, especially with the advent of commerce on the Internet, to protect information sent over the Internet against interception, examination, and/or alteration, as well as to authenticate the source or destination of the information.
As known in the art, Internet Protocol is a common addressing protocol designed to facilitate the routing of traffic within a network or between networks. For more information on IP, see RFC 791, specifically incorporated herein by reference. Currently, a number of security options exist for Internet users implementing IP, including the Internet Protocol Security (“IPSEC”). IPSEC is a set of protocols for implementing security for communications on networks through the use of cryptographic key management procedures and protocols. For more information on IPSEC, see Internet Engineering Task Force (“IETF”), Requests For Comments (“RFC”) 2401, specifically incorporated herein by reference.
The applications of IPSEC are numerous, including virtual private networks (“VPNs”), secure remote access, email privacy, and electronic commerce. However, in order for two network devices to communicate securely, they must be able to exchange keying material, typically over an insecure channel. Indeed, secure key exchange is an integral prerequisite of the IPSEC set of Internet security standards, and a comprehensive suite of protocols for allowing secure key exchange have been developed. The IPSEC standard for secure key exchange is the Internet Key Exchange (“IKE”) protocol. IKE allows two hosts to derive session keys via a series of messages that provide authentication and protection against flooding, replay, and spoofing attacks. IKE relies on the same cryptographic innovations that power most network security systems: public-key cryptography, such as Diffie-Hellman exchanges and RSA public-key/private-key pairs, symmetric-key cryptographic ciphers (e.g., data encryption algorithm (“DES”), triple DES (“3DES”), and international data encryption algorithm (“IDEA”)), and hashing algorithms for authentication (e.g., MD5 and secure hash algorithm (“SHA”)). For more information on IKE, see RFC 2409, specifically incorporated herein by reference.
IKE also allows the use of a public-key infrastructure, which is an architecture that allows entities to place their public key(s) into certificates. These certificates are data structures that bind the public key(s) to the entity. The binding is achieved by having a trusted third party (i.e., a certification authority (“CA”)) digitally “sign” an entity's certificate. Typically, the CA will first verify that the public-key belongs to the entity through some out-of-band means, such as a phone call or a physical meeting. Thus, any second entity that trusts the CA will be reasonably assured of the certificate's veracity. By the establishment of a hierarchy of CAs, anyone with Internet access will be able to verify the public key of an entity that offers a certificate. Entities may store their certificates in public databases to ease retrieval. IKE typically uses such a public-key infrastructure in order for participants to authenticate themselves to one another when using public-key cryptography. The public-key infrastructure currently being standardized for the Internet is based on the framework set forth in the International Telecommunications Union Recommendation X.509, specifically incorporated herein by reference. For more information on Internet X.509 security certificates, see RFC-2459, specifically incorporated herein by reference. For more information on X.509 security certificate management, see RFC-2510 and RFC-2511, both of which are specifically incorporated herein by reference.
Other members of the IPSEC suite of protocols include the Internet Security Association and Key Management Protocol (“ISAKMP”), the ISAKMP Domain of Interpretation (“DOI”), and OAKLEY. ISAKMP provides detailed protocol descriptions and packet formats for IKE. The packet formats are created through the use of over a dozen different payload formats, which may appear in various combinations. Each payload holds a particular type of data used in key exchange, and contains a pointer to the next payload in the packet. By stringing together a series of these payloads, ISAKMP packets can contain all of the data necessary for a particular IKE message. ISAKMP also defines the processing requirements for each header. For more information on ISAKMP, see RFC 2408, specifically incorporated herein by reference.
Some packet formats and field values are not defined in ISAKMP, but instead are defined in the ISAKMP DOI. The ISAKMP DOI (also referred to as the IPSEC DOI, or just the DOI) defines an IPSEC-specific interpretation of certain parts of ISAKMP headers and payloads. For example, the DOI defines how to interpret ISAKMP fields that refer to specific encryption and authentication algorithms, and defines packet formats for holding IP addresses. For more information on ISAKMP DOI, see RFC 2407, specifically incorporated herein by reference.
OAKLEY describes a family of canonical key exchange sequences and the security properties of each. Only a subset of the OAKLEY exchanges are used with IKE. The strengths of various encryption groups are presented as well. OAKLEY also discusses deriving new keys from existing keys and some protocol issues, such as how to handle message timeouts and how to format certain values. Overall, OAKLEY focuses on the mathematical side of key exchange, and serves as a guide for implementing protocols. For more information on OAKLEY, see RFC 2412, specifically incorporated herein by reference.
Varying Strength For Internet Security Needed
As explained above, Internet security is largely based on cryptographic keys. Such keys may vary in bit length, with a larger bit length indicating a stronger encryption and Internet security, and a smaller bit length indicating a weaker encryption and Internet security. Under certain circumstances, it may be necessary or desirable to use Internet security with varying encryption strengths. The prior art, however, does not disclose a security system or method that is capable of restricting a network device from using stronger encryption regardless of local policy.
As an example of the need for varying security strength, the United States (“U.S.”) government now freely allows export of IPSEC network client devices outside of the U.S. (“foreign devices”) that are capable of doing data encryption with keys greater than 64 bits, but only if the connection (i.e., data traffic) is between the foreign devices and a peer network device (e.g., a server) residing in the U.S. Unless government approval is sought and given, however, each foreign device should not have the capability to do any encryption with keys greater than 64 bits if its peer is not in the U.S. By doing this, government agencies can monitor the data encrypted with greater than 64 bit keys, if so desired, by contacting the authorities who own the IPSEC network device in the U.S. (e.g., the U.S. server).
As another example of the need for varying security strength, some foreign governments regulate the bit length of encryption keys used by imported network devices. For instance, France requires government approval for importing network devices into the country that are capable of doing data encryption with keys greater than 40 bits in length. Consequently, network devices being imported into France (or any similar foreign country) must be custom designed to account for this encryption limitation to avoid government interference. Such customization is often complex and costly for network device manufacturers.
As a result of these regulations, U.S. based organizations, such as financial institutions, that have overseas satellite offices are purchasing IPSEC network client devices from overseas vendors, so that they can perform encryption with more that 64 bit keys in their sites not within the U.S. In other words, overseas vendors are not limited by their respective countries to encryption with no greater than 64 bit keys. Consequently, U.S. vendors of IPSEC solutions are losing a large overseas market share. In addition, network device manufacturers are being forced to specially customize their network devices for importing into certain foreign countries that require government approval for stronger encryption.
Accordingly, it would be desirable to provide an Internet security system and method that enables a network device to selectively use both stronger encryption (i.e., greater than 64 key bits) and weaker encryption (i.e., no greater than 64 bit keys) automatically, depending on one or more factors, such as location. More specifically, it would be desirable to provide an Internet security system and method that enables a foreign network device to implement stronger encryption via greater than 64 bit keys (or some other threshold key length) with other network devices residing in the U.S., yet automatically prevents the foreign network device from implementing such stronger encryption with other network devices not residing in the U.S. It would also be desirable to provide such selective strength encryption without resorting to complex and costly customizing procedures.